Columbia Kermit/kermit.zip/newsgroups/misc.19950726-19950929/[e-mail]_Mon Sep 4 03:31:15 1995.msg

Internet Message Format | 2020-01-01 | 4KB

Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA11811
  (5.65c+CU/IDA-1.4.4/HLK for <[e-mail]>); Mon, 4 Sep 1995 12:20:13 -0400
Received: by apakabar.cc.columbia.edu id AA08449
  (5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Mon, 4 Sep 1995 12:20:11 -0400
Path: news.columbia.edu!panix!news.mathworks.com!newsfeed.internetmci.com!inet-nntp-gw-1.us.oracle.com!news.caldera.com!news.cc.utah.edu!news.cs.utah.edu!cc.usu.edu!jrd
From: [e-mail] (Joe Doupnik)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: MS-KERMIT 3.14 hanging on idle TCP/IP connection?
Message-Id: <[e-mail]>
Date: 4 Sep 95 09:31:15 MDT
References: <42d2u9$[e-mail]> <42dodl$[e-mail]>
Organization: Utah State University
Lines: 78
Apparently-To: [e-mail]

In article <42dodl$[e-mail]>, [e-mail] (Seth Chaiklin) writes:
> Joe Doupnik <[e-mail]> wrote:
>>    Did you have a chance to look at the ARP cache on the Linux machine?
>>I've heard rumors (I don't use Linux) that it times out and can yield just
>>the effects noted. You might try pinging MSK from the Linux end as one way
>>of correcting its ARP cache.
>
> You are definitely on the right track (and thanks for the fast response!).
>
> I tried an experiment.  I let the MSK machine sit idle while
> connected to the Linux machine, and after 10 minutes (while true;
> do date; arp -a; sleep 60; done), I discovered that the Linux arp
> cache loses the HW address of the ethernet card, at which point,
> of course, the MSK machine appears to be frozen.
>
> I tried pinging the MSK machine from the Linux machine, but it
> does not respond.  However, if I hand-entered the HW address for
> the MSK machine, then deleted this entry from the arp cache, and
> then added it again, I could reestablish input/output being shown
> on the MSK machine, and everything seems to work as it should.
>
    Looks as if you need to talk with the Linux folks about fixing
the mis-designed TCP/IP stack.

>>    You should also double check memory management on the PC to avoid
>>clobbering the Ethernet adapter (presumed, you didn't say), and also to
>>seek out and destroy IRQ & port conflicts. Remember to leave video memory,
>>segments A000-BFFF, to the video system. These matters are discussed in
>>the release notes. Do worry about PC screen savers and green machine
>>power-downs too.
>
> Thanks for these additional suggestions.  Good to know for the future,
> but the machine where I was having the problems is:
>
> An elder XT with 640K.  There is no memory to manage, and
> definitely not green!  There are no screen savers.  There are
> keyboard and codepage drivers installed, as well as a Cyrnwr packet
> driver, otherwise no other TSRs. The monochrome monitor has a
> hercules-compatible card.  There is a single serial port IRQ4, and
> the ethernet adapter is IRQ3.  The ethernet adaptor is a 3c501.

    3C501? Yikes, that's a very poor board on any network these
days. NE-2000 clones cost very little and I recommend putting the 3C501
in the museum drawer (please).

> However, I tried the same experiment (with the same results) with
> a 486 VGA monitor machine and a 3c509 ethernet card, so I
> suspect the problem is not with MSK nor with the PC-hardware.
>
> However, there is still one part that bothers me:  Why would MSK crash
> the PC in the process of exiting from MSK?  This happens even if I
> logout from the Linux machine (because it is still possible to
> issue commands, even if the arp cache has lost the ethernet address,
> and if it they are not shown on the monitor).  That doesn't seem
> right. (It doesn't crash if I reload the arp cache.)

    I have no idea, to tell the truth. MSK doesn't crash here when
the other end goes away. It takes awhile to time out but that's all.
I'm typically using ODI rather than a Packet Driver.
    Joe D.

> Meanwhile, thanks very much for the insightful suggestion.
>
> Cheers,
>   Seth Chaiklin
>
>
>
>
>
>
>
>
>
>
>
>
>